REMARKS 



Claims 16-20 and 38-41 are pending in the present application. By this Response, 
claim 18 is amended to place it in independent form. Claims 16 and 38 are amended to 
correct typographical errors. Claims 39-41, which correspond to claims 17, 19 and 20 
but are dependent from claim 18, are added. No new matter has been added by the 
amendments or additional claims. Reconsideration of the claims is respectfully 
requested. 

Amendments are made to the specification to write out the term M ND" as 
requested by the Examiner in the Office Action and to remove the reference numeral 
"400" from the description of Figure 4. No new matter has been added by any of the 
amendments to the specification. 

Also, applicants have submitted proposed corrections as suggested by the 
Examiner in red ink. These changes will be incorporated into a formal set of drawings 
upon approval of the proposed changes by the Examiner. 

I. Allowable Subject Matter 

Applicants thank Examiner Cardone for the indication of allowable subject matter 
in claim 18. By this Response, claim 18 is amended to be in independent form by 
incorporating the subject matter of independent claim 16 from which it depended. In 
addition, claims 39-41 are added as dependent claims that are dependent from allowable 
claim 18. Accordingly, it is Applicants' understanding that claims 18 and 39-41 now 
stand in condition for allowance. 

IL Objections to Figures and Specification 

The Office Action objects to the figures as including reference numerals that are 
not described in the specification and not having some reference numerals that are 
referred to in the specification. Specifically, Figure 4 is objected to as not having the 
reference numeral "400," Figure 5 is objected to for not including reference numerals 
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"648" and "640," Figure 5 is further objected to for including reference numeral "541" 
which is not described in the specification, and Figure 2 is objected to for allegedly 
having the typographical error "sever." 

By this Response, a replacement sheet for Figure 5 is provided that amends the 
figure to remove the reference numeral "541" and to change one of the reference 
numerals "548" to be "546" in correspondence with the specification. The specification 
does not make reference to numerals "648" and "640" when describing Figure 5 and thus, 
there is no need to include these reference numerals in Figure 5. To the contrary, 
elements 648 and 640 appear in Figure 6. 

With regard to Figure 4, the reference to numeral "400" in the specification has 
been removed by the amendments to the specification above and thus, there is no need to 
include reference numeral 400 in Figure 4. Regarding claim 2, formal drawings were 
submitted on December 14, 2001 in which the term "sever" was corrected. 

In view of the above amendments to Figure 5 and the specification, Applicants 
respectfully request withdrawal of the objection to the drawings and the specification. 

III. Alleged Double Patenting 

The Office Action rejects claims 16, 17, 19 and 38 as being allegedly anticipated 
by claims 8-31 of U.S. Patent No. 5,371,852 and thus, constituting double patenting. 
Applicants respectfully submit that claims 16, 17, 19 and 38 are not double patenting in 
view of claims 8-31 of Attanasio et al, U.S. Patent No. 5,371,852 (hereafter referred to as 
"Attanasio"). 

Claims 16, 17, 19 and 38 all recite a dispatch layer that is between a TCP layer 
and an IP layer. None of the claims 8-31 of Attanasio teach or suggest a dispatch layer 
between a TCP layer and an IP layer. While the claims mention IP message headers, 
routing of messages, TCP port numbers, and TCP messages, there is no teaching or 
suggestion in any of claims 8-31 of Attanasio regarding a dispatch layer between an IP 
layer and a TCP layer. Furthermore, the Office Action fails to indicate where such a 
feature is taught or suggested in any of the claims 8-31. Moreover, the Office Action 
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fails to provide any teaching, suggestion or motivation to modify the invention recited in 
claims 8-31 of Attanasio to include a dispatch layer between a TCP layer and an IP layer. 

Furthermore claims 16, 17 and 19 all recite that the dispatch layer has a plurality 
of modes of operating including a first mode of operation in which the dispatch layer 
receives a packet from a client, wherein the packet includes the destination address; a 
second mode of operation, responsive to receiving the packet, in which the dispatch layer 
identifies a process within the plurality of processes to service the client, wherein the 
process is an identified process; a third mode of operation in which the dispatch layer 
translates the destination address to a process address for the identified process within the 
plurality of processes; and a fourth mode of operation, responsive to the third mode of 
operation, in which the packet is sent to the packet routing layer. Claims 8-31 of 
Attanasio do not teach or suggest any dispatch layer, let alone a dispatch layer between a 
TCP layer and an IP layer, that has these four modes of operation. Again, the Office 
Action fails to show where any of these features are taught or suggested in any of claims 
8-31 of Attanasio and fails to provide any suggestion or motivation for including such 
features in the invention recited in claims 8-31 of Attanasio. 

Claim 38 further recites that the dispatch layer, that is between a TCP layer and an 
IP layer, translates a destination address to an intermediate destination address which is 
an address for a selected process within a plurality of processes. None of the claims 8-31 
teach or suggest a dispatch layer that is between a TCP layer and an IP layer that also 
translates destination addresses into intermediate destination addresses for a selected 
processes within a plurality of processes. Again, the Office Action fails to identify so 
much as a single claim where such features are taught or suggested. Rather, the Office 
Action merely makes an allegation that the features of the claims are taught in claims 8- 
31, i.e. 23 claims. The Office Action fails to point to any teaching in any of the claims 
with particularity as teaching these features or even suggesting these features and thus, 
has failed to establish a case of double patenting with regard to claim 38. 

In view of the above, Applicants respectfully submit that claims 16, 17, 19 and 38 
are not double patenting in view of claims 8-31 of Attanasio and the rejection should be 
withdrawn. Accordingly, Applicants respectfully request withdrawal of the rejection of 
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claims 16, 17, 19 and 38 under alleged double patenting based on claims 8-31 of 
Attanasio. 



IV. 35 U.S.C. § 102, Alleged Anticipation 

The Office Action rejects claims 16, 17, 19 and 38 under 35 U.S.C. § 102(e) as 
being anticipated by Brendel et al. (U.S. Patent No. 5,774,660). This rejection is 
respectfully traversed. 

As to independent claims 16 and 38, the Office Action states: 

10. Regarding claims 16 and 38, Brendel discloses a computer 
comprising: 

a plurality of processes, wherein the plurality of processes service 
a destination address and have process addresses [Brendel, col. 13, lines 
18-46]; 

a packet routing layer, wherein the packet routing layer routes a 
packets to the plurality to the plurality of processes using a destination 
addresses within the packets [ie. TCP layer, Brendel, col. 13, lines 18-46]; 

a dispatch layer between a TCP layer and an IP layer, wherein the 
dispatch layer has a plurality of modes of operation including: a first 
mode of operation in which the dispatch layer receives a packet from a 
client, wherein the packet includes the destination address [ie. raw socket, 
Brendel, col. 14, line 56 - col. 15, line 56]; 

a second mode of operation, responsive to receiving the packet, in 
which the dispatch layer identifies a process within the plurality of 
processes to service the client, wherein the process is an identified process 
[Brendel, col. 14, line 41-col. 15, line 16]; 

a third mode of operation in which the dispatch layer translates the 
destination address to a process address for the identified process within 
the plurality of processes; 

and a fourth mode of operation, responsive to the third mode of operation, 
in which the packet is sent to the packet routing layer [Brendel, col. 17, 
lines 9-26]. 

Office Action dated April 28, 2004, pages 4-5. 
Claim 16 recites: 
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16. A computer comprising: 

a plurality of processes, wherein the plurality of processes service 
a destination address and have process addresses; 

a packet routing layer, wherein the packet routing layer routes 
packets to the plurality of processes using a destination addresses within 
the packets; 

a dispatch layer between a TCP layer and an IP layer, wherein the 
dispatch layer has a plurality of modes of operation including : 

a first mode of operation in which the dispatch layer receives a 
packet from a client, wherein the packet includes the destination address; 

a second mode of operation, responsive to receiving the packet, in 
which the dispatch layer identifies a process within the plurality of 
processes to service the client, wherein the process is an identified 
process; 

a third mode of operation in which the dispatch layer translates the 
destination address to a process address for the identified process within 
the plurality of processes; and 

a fourth mode of operation, responsive to the third mode of 
operation, in which the packet is sent to the packet routing layer. 

A prior art reference anticipates the claimed invention under 35 U.S.C. § 102 only 
if every element of a claimed invention is identically shown in that single reference, 
arranged as they are in the claims. In re Bond, 910 R2d 831, 832, 15 U.S.P.Q.2d 1566, 
1567 (Fed. Cir. 1990). All limitations of the claimed invention must be considered when 
determining patentability. In re Lowry, 32 F.3d 1579, 1582, 32 U.S.P.Q.2d 1031, 1034 
(Fed. Cir. 1994). Anticipation focuses on whether a claim reads on the product or process a 
prior art reference discloses, not on what the reference broadly teaches. Kalman v. 
Kimberly-Clark Corp., 713 F.2d 760, 218 U.S.P.Q. 781 (Fed. Cir. 1983). Applicants 
respectfully submit that Brendel does not identically show every element of the claimed 
invention arranged as they are in the claims. Specifically, Brendel does not teach a 
dispatch layer between a TCP layer and an IP layer or such a dispatch layer that has the 
four modes of operation recited in claim 16. 

Brendel is directed to a system for resource-based load balancing on a distributed 
resource multi-node network. With the system of Brendel, a load balancer receives all 
requests from clients using virtual address for a web site. The load balancer makes a 
connection with the client and waits for a URL of the resource requested by the client. The 
load balancer waits to perform load balancing until after the location of the requested 
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resource is known. The connection and URL request are passed from the load balancer to a 
second node having the requested resource. The load balancer re-plays the initial 
connection packet sequence to the second node but modifies the address to that of the 
second node. The network software is modified to generate the physical network address 
of the second node but then changes the destination address back to the virtual address. 
Since all requests are first received by the load balancer which determines the physical 
location of the requested resource, nodes may contain different resources. The entire 
contents of the web site are not mirrored onto all nodes. Network bottlenecks are avoided 
since the nodes transmit files back to the client directly, bypassing the load balancer. 

Thus, Brendel teaches a load balancing mechanism in which a load balancer 
identifies the location of a requested resource and then modifies the virtual address 
received from the client to an address for the node having the requested resource. The node 
may then use the virtual address to directly communicate the requested resource to the 
client without having to go through the load balancer. Brendel does not teach a dispatch 
layer that is between a TCP layer and an IP layer. Furthermore, Brendel does not teach a 
dispatch layer that is between a TCP layer and an IP layer and that has the four modes of 
operation recited in claim 16 of the present application. 

The Office Action alleges that Brendel teaches a dispatch layer that is between a 
TCP layer and an IP layer at column 14, line 56 to column 15, line 56 which reads as 
follows: 

Local packets that are not of a known protocol such as TCP or 
UDP (User Datagram Protocol) have an unrecognized protocol. These 
datagrams are sent to raw socket 214, bypassing TCP module 218. Any 
applications in application layer 80 can listen to raw socket 214 and use 
the datagram, since raw sockets are a standard TCP/IP feature. Load 
balancer 70 is an application which listens to raw socket 214 for 
datagrams using the "IXP M protocol. Since the IXP protocol is not a 
defined protocol, no other applications should be looking for IXP 
datagrams. Thus using the IXP protocol allows use of raw socket 214 to 
bypass the TCP layer and send the datagrams directly to load balancer 70. 
These datagrams are the connection packets and the URL originally from 
the client's browser. 

Each server is modified to accept packets using the virtual IP 
address by aliasing a second IP address, thus using two IP addresses. For 
example, in UNIX, the command: 
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% ifconfig deO 230.101.17.200 alias netmask Oxffffffff 



specifies that a second IP address, the virtual IP address 230.101.17.200 is 
also an IP address for the node. Other operating systems also support IP 
address aliasing. 

Modified IP Input Module-FIG. 15 

FIG. 15 is a flowchart for a modified IP layer input module. The 
server with the load balancer uses modified IP input module 200 . An 
asterisk is used to indicate that the module is modified from the generic 
ip_ input() module. Steps 308, 310, 312, and 314 are added steps which 
are not in the generic IP module. 

All packets received from the media by the lower link layer are 
passed up to the IP layer which calls IP input module 200 . Step 302 tests 
to determine if the packet is for the local node by reading the destination 
IP address. 

When step 302 determines that the destination IP address is not a 
local IP address, then the packet is being routed through the local node and 
the IP layer acts as a software router. The packet is passed to IP forward 
module 202 (step 304) which prepares the packet for forwarding. The 
packet is then sent to IP output module 206 before being re-transmitted out 
the link layer to the destination or the next hop. 

Step 302 determines that the packet is for the local node when the 
IP address is the virtual IP address or the real IP address for the server. 
The packet is stripped of its header information and possibly assembled 
with other packets to form the IP datagram, step 306. 

The assembled IP datagram from step 306 is normally sent up to 
the TCP layer (steps 316, 318) for the generic IP module. The invention 
performs additional steps before step 306 by modifying the generic IP 
input module to form modified IP input module 200 . Modified IP input 
module 200 checks the protocol to determine if it is the IXP protocol . 
Since incoming packets from the Internet always use the TCP protocol, 
incoming packets fail step 308 and are then tested by step 310 to 
determine if they are TCP packets with the virtual IP address and are 
world-wide- web packets. Thus step 310 looks for incoming packets. These 
incoming packets have their protocols changed from TCP to IXP , step 
314. The IXP protocol is not a recognized protocol so step 316 causes 
these incoming packets to be sent to the raw socket, step 320, so that the 
load balancer application can read these packets . Thus changing the 
protocol to the unrecognized IXP protocol forces the incoming packets to 
be sent directly to the load balancer. This allows all incoming packets 
from the Internet to be routed through the load balancer. 

Other TCP packets which are not world-wide web packets fail step 
310 and are not modified. These ordinary TCP packets are a known 
protocol, step 316, and are sent to the TCP layer, step 318. 



Page 12 of 16 
Dingsor et al. - 09/976,126 



(emphasis added) 



The most pertinent part of the above cited portion of Brendel is the description of 
Figure 15. This description states that the IP layer calls the modified IP module 200. 
The modified IP module 200 checks to see if a received data packet is in the IXP protocol 
and if not, converts the data packet from TCP to IXP so that the data packet is directly 
sent to a raw socket for reading by the load balancer. There is no mention of any 
dispatch layer between a TCP layer and an IP layer in this, or any other, section of 
Brendel. While the TCP layer and the IP layer are mentioned, the actual functions of 
converting protocols from TCP to IXP is performed in the IP layer by calling a modified 
IP module 200. Furthermore, the functions that are performed by this modified IP 
module 200 merely converts protocols and does not perform the functions of the dispatch 
layer as recited in claim 16. 

Claim 16 specifically recites that the dispatch layer has four modes of operation. 
A first mode of operation is one in which the dispatch layer receives a packet from a 
client, wherein the packet includes the destination address. A second mode of operation 
is one in which, responsive to receiving the packet, the dispatch layer identifies a process 
within the plurality of processes to service the client, wherein the process is an identified 
process. Nowhere in the cited section of Brendel is there any teaching of a dispatch 
layer, that is between a TCP layer and an IP layer, that performs the function of the 
second mode set forth in claim 16. 

The Office Action alleges that this second mode of operation is taught by Brendel 
at column 14, line 41 to column 15, line 16 which is part of the reproduced section of 
Brendel above. However, nowhere in this section is there any teaching regarding a 
dispatch layer between a TCP layer and an IP layer, identifying a process within a 
plurality of processes to service a client. In fact, the section cited as allegedly teaching 
these features is under the heading "Modified IP layer - FIG. 14" (column 14, line 38). 
Furthermore, the section discusses determining if the packet is destined for a local node 
or another node and that local packets are assembled into IP datagrams. There is not 
teaching or even suggestion regarding a dispatch layer between an IP layer and a TCP 
layer identifying a process within a plurality of processes to service a client. 
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A third mode of operation of the dispatch layer, as recited in claim 16, is one in 
which the dispatch layer translates the destination address to a process address for the 
identified process within the plurality of processes. Again, there is no teaching or 
suggestion in Brendel with regard to a dispatch layer between a TCP layer and an IP layer 
performing such a function. The Office Action fails to cite a specific portion of the 
reference that allegedly teaches this feature. The Office Action does cite column 17, 
lines 9-26 as allegedly teaching the fourth mode of operation and it may be that the 
Office Action intends to state that this section also teaches the features of the third mode 
of operation, it is unclear. However, the cited section does not teach either of the features 
of the third mode or the fourth mode of operation which is one in which, responsive to 
the third mode of operation, in which the packet is sent to the packet routing layer. 

Column 17, lines 9-26 reads as follows: 

Incoming packets which are assigned to the load balancer node's 
server are passed up and down the local TCP/IP stack twice. These 
packets are first sent from the low-level link layer through the modified IP 
layer to the load balancer in the application layer, and then back down 
through the IP layer to the link layer. Step 336 of FIG. 16 detects that the 
local server is the destination and bypasses steps 338, 340 so that the 
protocol is left as IXP. 

The link layer recognizes that the NIC address is the local NIC 
address and does not transmit the packets. Instead the packets are sent 
back up to the IP layer. Step 308 of FIG. 15 detects these packets and 
changes the protocol back to TCP (step 312) and then passes the TCP 
packets to the HTTPD server application through the generic TCP layer. 
This sequence only occurs for a packet that has been intercepted to the 
load balancer and assigned to the server on the local node. 

This section of Brendel provides further support for the distinction of the present 
claims reciting a dispatch layer between an IP layer and a TCP layer, a feature not taught 
by Brendel. This section of Brendel states that the packet is sent from the link layer to 
the modified IP layer and then to the application layer bypassing the TCP layer. Thus, 
Brendel teaches a mechanism in which the IP layer is modified to bypass the TCP layer 
and send data packets directly to the load balancer in the application layer. Brendel does 
not teach or suggest a dispatch layer between a TCP layer and an IP layer. 



Page 14 of 16 
Dingsor et al. - 09/976,126 



Brendel further does not teach a dispatch layer that performs the functions of 
operational modes three and four in claim 16. That is, there is not teaching in the above 
cited section regarding a dispatch layer between a TCP layer and an IP layer that 
translates a destination address to a process address for an identified process within a 
plurality of processes or that, responsive to this translation, sends the packet to a packet 
routing layer. While Brendel may teach modifying protocols from TCP to IXP and back 
again, there is nothing in Brendel that teaches a dispatch layer between a TCP layer and 
an IP layer that identifies a process from a plurality of processes to service a client, 
translates a destination address to a process address for the identified process, and then 
sends the data packet to a packet routing layer. 

Independent claim 38 recites some similar features to that of claim 16. 
Specifically, claim 38 recites instructions for translating, in a dispatch layer between a 
TCP layer and an IP layer, a destination address to an intermediate destination address 
which is an address for a selected process within a plurality of processes. Similar 
features to these have been addressed above with regard to claim 16 and thus, claim 38 is 
distinguished over the Brendel reference for similar reasons. Brendel does not teach or 
suggest these features in claim 38. 

In view of the above, Applicants respectfully submit that Brendel does not teach 
each and every feature of independent claims 16 and 38. At least by virtue of their 
dependency on claim 16, Brendel does not teach each and every feature of dependent 
claims 17 and 19. Accordingly, Applicants respectfully request withdrawal of the 
rejection of claims 16, 17, 19 and 38 under 35 U.S.C. § 102(e). 

V, 35 U.S.C. § 103, Alleged Obviousness 

The examiner has rejected claim 20 under 35 U.S.C. § 103(a) as being 
unpatentable over Brendel in view of Coile et al. (U.S. Patent No. 6,061,349). This 
rejection is respectfully traversed for at least the same reasons as set forth above with 
regard to independent claim 16 from which claim 20 depends. That is, Brendel does not 
teach a dispatch layer between a TCP layer and an IP layer or such a dispatch layer that 
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has the four modes of operation recited in claim 16. Coile, likewise, does not teach or 
suggest these features. 

Coile is cited merely as teaching server daemon processes. Coile does not 
provide for the deficiencies of Brendel and thus, any alleged combination of Brendel and 
Coile, even if such a combination were possible and one of ordinary skill in the art were 
somehow motivated to attempt such a combination, would not result in the invention as 
recited in independent claim 16, from which claim 20 depends. 

Therefore, Applicants respectfully submit that neither Brendel nor Coile, either 
alone or in combination, teach or suggest all of the features of claim 20. Accordingly, 
Applicants respectfully request withdrawal of the rejection of claim 20 under 35 U.S.C. § 
103(a). 

VI. Conclusion 

It is respectfully urged that the subject application is patentable over Brendel and 
Coile and is now in condition for allowance. The Examiner is invited to call the 
undersigned at the below-listed telephone number if in the opinion of the Examiner such 
a telephone conference would expedite or aid the prosecution and examination of this 
application. 



Respectfully submitted, 




Stephen J. SS/alder, Jr. 
Reg. No. 41,534 
Yee & Associates, P.C. 
P.O. Box 802333 
Dallas, TX 75380 
(972) 367-2001 
Attorney for Applicants 
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